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APPEAL BRIEF 

L REAL PARTY IN INTEREST 

The real party in interest is the assignee, Telefonaktiebolaget L M Ericsson 
(publ), a Swedish corporation. 

II. RELATED APPEALS AND INTERFERENCES 

There are no other appeals related to this subject application. There are no 
interferences related to this subject application. 

IH. STATUS OF CLAIMS 

Claims 1-20 are pending, twice rejected, and appealed. 
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IV. STATUS OF AMENDMENTS 

There are no amendments filed after the office action mailed February 3, 

2011. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 

The technology in this case relates to a method, network and devices for 
controlling mobile packet streams using middleboxes and midcom agents. As 
defined on page 1, lines 6-8 of the specification, "[a] mobile packet flow is a 
packet flow which during an ongoing communication session changes its way or 
route through the network, for example in consequence of a roaming mobile 
terminal or in consequence of a roaming mobile network." Lines 13-19 describe 
"middleboxes" as implementing "a large variety of network nodes, such as 
firewalls, network address translators (NAT), access routers and many other types 
of nodes. Middleboxes typically have corresponding application intelligence 
embedded within the device for their operation" which "may enforce application 
specific policy based functions such as quality of service (QoS) control, resource 
management, packet filtering, virtual private network (VPN) tunnelling, intrusion 
detection, security." Figure 1 below illustrates middleboxes (MBs) 4, 8 shows a 
connection between two terminals with separate session and IP layers. There are 
two separate signaling layers: one at the session layer and one at the IP layer. The 

2 

1844011 



Fodor et al 

Appl. No. 10/583,962 

session layer signaling may use the SIP signaling protocol and the IP layer control 
signaling may use the RSVP signaling protocol. 




When the route of a moving user data flow is changed, the combined user 
data packet flow and IP layer control signaling encounter routers, middleboxes, 

and other network nodes that have no knowledge of the flow, and therefore, do not 

know how to handle the flow, where it should be routed, which resources it 

requires, what the authentication and accounting status might be, etc. To solve 

this problem, control messages are transferred to middleboxes in order to ascertain 

that a user data IP flow is processed correctly. By separating the user data plane 

from the IP control plane and registering the flows with the midcom agent, the 

midcom agent then sends control messages, related to individual user data flows, 

to middleboxes, routers, and other nodes along the paths the individual flows 

traverse. As a result, the signaling is faster and is done from one unit — a midcom 

agent. The use of two separate signaling protocols to set up a session is eliminated 

thereby reducing complexity and bandwidth requirements. Upgrading of software 
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is facilitated since only one control entity, the midcom agent, needs to be 
upgraded. The central midcom agent also makes it is possible to handle flows in a 

consistent manner and avoid feature interaction. 

An example embodiment is shown in Figure 2 reproduced below: 




A midcom agent (MA) 15 is arranged at the IP control plane and controls 
how the middleboxes (MB) 13 handle an individual user data flow shown with a 
bold thick black line. Control functions (e.g., relating to resource management, 
resource control, QoS control, firewalls, network address translators, etc.) are 
performed according to the session parameters for bandwidth and QoS that are 
negotiated using the session layer signaling protocol. 
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Because mobility can change the user flow path, leaving the IP control 
layer in a bit of a control dilemma, the user flow itself registers its presence at the 
middleboxes it encounters on the IP user data plane on its way from source 
terminal to destination terminal. Each middlebox where a flow registers in turn 
reports the identity of the reported flow and its own identity to the midcom agent. 
This combined flow and middlebox registration is shown by the vertical arrow 16. 
In response, the midcom agent searches for functions related to the individual 
flow, and when found, the midcom agent sends a corresponding flow control 
message(s) to the reporting middlebox as shown by vertical arrow 17. 

The following mapping of the independent claims onto example 
embodiment text from the specification and figures by reference numerals is not 
intended to be limiting or to be used for claim construction. 

1. A method for control of mobile packet flows forwarded on an IP -based 
user plane (6), where each mobile user data packet flow is separate and different 
from session set up messages sent with IP layer control signaling and/or session 
layer control signaling, comprising the steps of : 

a. controlling individual mobile user data packet flows forwarded on the IP- 
based user plane (6) from a common, IP-based control plane (4) provided 
with one or more midcom agents (15), where the common, IP-based 
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control plane is separate from the IP-based user plane (Figs. 2, 3) (page 6, 
lines 13-26), said control being provided by: 

b. each mobile user data packet flow registering its presence in each 
middlebox (13) it encounters on its way from its source (1, 3) to its 
destination (1, 3) in the IP-based user plane (page 6, lines 30-31), and 

c. in response to step b, each middlebox (13) in the IP-based user plane (6) 
registering itself and the identities of mobile user data packet flows it 
handles in the IP-based user plane at a midcom agent (14) in the common, 
IP-based control plane (4) using an extended midcom signalling protocol 
(16) (page 6, line 31 -page 7, line 6), and 

d. after step c, the midcom agent signalling control orders (17) to the 
registered middleboxes, said orders pertaining to the handling of the 
mobile user data packet flows at respective middleboxes in the IP-based 
user plane (page 7, lines 6-9, page 10, lines 8-12). 

13. A communication system comprising: 

a plurality of IP based networks (Figures 6 and 8); 

a session controller (2) for set up of a communication path that traverses 

selected one of the networks, each selected network having an ingress middlebox 

(IN) at which a user data packet flow enters the network and an egress middlebox 

(EN) at which the flow exits the network, where the user data packet flow (6) is 
6 
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separate and different from session set up messages sent with IP layer control 
signaling and/or session layer control signaling (9), 

each network comprising: 

a midcom agent (MA) located in an IP control plane (4), 

a plurality of middleboxes (MBs) located in an IP user plane (6) 
separate from the IP control plane, 

an extended midcom protocol allowing for communication between 
the midcom agent and the middleboxes (page 7, lines 14-20, page 10, lines 1 1-12, 
page 12, lines 13-14), 

wherein said middleboxes are configured to detect a user data packet flow 
forwarded on the IP-based user plane and register its identity at the midcom agent 
located in the IP control plane together with the identity of the middlebox at which 
the user data packet flow was detected (16) (page 6, line 31 -page 7, line 6), and 

wherein said midcom agent, in response to a combined flow and 
middlebox registration, is configured to send a flow control order (17) to the 
middlebox in the IP-based user plane using the extended midcom protocol, said 
flow control order instructing the middlebox how to handle the detected user data 
packet flow in the IP-based user plane (page 7, lines 6-9, page 10, lines 8-12). 
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15. A midcom agent (15) located in a control plane (4) for controlling 
mobile user data packet flows over an IP-based user plane (6) separate from the 
control plane, where each mobile user data packet flow is separate and different 
from session set up messages sent with IP layer control signaling and/or session 
layer control signaling, comprising electronic circuitry configured to: 

receive a middlebox registration message from each of multiple 
middleboxes in the IP-based user plane (page 9, lines 14-15 and 32-page 10, line 
2); 

register each middlebox for which a middlebox registration message is 
received (page 7, lines 5-8); 

receive from each of the registered middleboxes one or more mobile user 
data packet flows being handled by each of the registered middleboxes in the IP- 
based user plane (page 9, lines 14-16); and 

signal a control order (17) to each of the registered middleboxes for 
handling the mobile user data packet flows at each of the registered middleboxes 
(page 7, lines 6-9, page 10, lines 8-12). 

20. A middlebox (13) for controlling mobile user data packet flows over 
an IP-based user plane (6), where each mobile user data packet flow is separate 
and different from session set up messages sent with IP layer control signaling 
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and/or session layer control signaling, comprising electronic circuitry configured 
to: 

receive a midcom agent announcement message, the midcom agent located 
in a control plane (4) separate from the IP-based user plane (6) in which the 
middlebox is located (page 9, lines 10-13); 

send a middlebox registration message to the midcom agent (page 9, lines 
14-15); 

send a mobile user data packet flow registration message (16) to the 
midcom agent for one or more mobile packet user data flows being handled by the 
middlebox in the IP-based user plane (page 9, lines 14-16); and 

receive a control message (17) from the midcom agent in the control plane 
for handling the one or more mobile user data packet flows in the IP-based user 
plane (page 7, lines 6-9, page 10, lines 8-12). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The first ground of rejection to be reviewed by the Board is the rejection of 
claims 1-2, 4-10, 12, 15-20 under 35 U.S.C. §103 as being unpatentable based on 
Mitchell and Suzuki. 

The second ground of rejection to be reviewed by the Board is the rejection 
of claims 13 and 14 under 35 U.S.C. §103 as being unpatentable based on 
Mitchell, Suzuki, and Das. 
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The third ground of rejection to be reviewed by the Board is the rejection of 
claims 3 and 1 1 under 35 U.S.C. §103 as being unpatentable based on Mitchell, 
Suzuki, and Ramsayer. 

VII. ARGUMENT 

The Obviousness Rejection of Claims 1-2, 4-10, 12, and 15-20 under 35 U.S.C. 
§103 as being Unpatentable Based on Mitchell and Suzuki Is Improper 

1. The Legal Standard For Obviousness 

An invention is obvious only "if the differences between the subject matter 
sought to be patented and the prior art are such that the subject matter as a whole 
would have been obvious at the time the invention was made to a person having 
ordinary skill in the art to which the subject matter pertains." 35 U.S.C. §103. 
Obviousness is a legal conclusion based on underlying findings of fact. In re 
Dembiczak, 175 F.3d 994, 998 (Fed. Cir. 1999). The underlying factual inquiries 
are: "(1) the scope and content of the prior art; (2) the level of ordinary skill in the 
prior art; (3) the differences between the claimed invention and the prior art; and 
(4) objective evidence of nonobviousness." Id. 

In KSR International Co. v. Teleflex, Inc., 127 S. Ct. 1727, 1739 (2007), the 
Supreme Court rejected the Federal Circuit's rigid application of the teaching- 
suggestion-motivation ("TSM") test. However, in evaluating obviousness in light 
of multiple interrelated patents, a determination must still be made "whether there 

was an apparent reason to combine the known elements in the fashion claimed by 
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the patent at issue." Id. at 1741. The Examiner must provide an explicit analysis 

with supported, articulated reasoning, that includes "an apparent reason to 

combine the known elements" in the manner claimed. Id. at 1740-41 ("To 

facilitate review, this analysis should be made explicit."). The Supreme Court 

stated that this requirement cannot be satisfied by conclusory statements without 

articulated reasoning and some rational underpinning to support the legal 

conclusion of obviousness. Id. at 1741. 

2. Mitchell and Suzuki Lack the Registration and Control of User 
Data Packet Flows 

Mitchell describes discovering and registering middleboxes in response to a 

call set-up message. For the middlebox "binding" referred to in [0062], the call 

servers 18 request the middlebox to set up a voice packet path from terminal A, 

and in response, the middlebox replies with a public address and port to which 

packets from terminal B to terminal A should be sent. Unlike the claims which 

relate to the registration and control of mobile user data packet flows for 

purposes such as QoS differentiation or transcoding, Suzuki deals with something 

entirely different — address assignment. See, e.g., Suzuki's title "Network address 

assigning system," abstract: "A network address assigning system. . .," and 

summary and claims: "A network address assigning system. ..." 

Step (a) of claim 1 recites "controlling individual mobile user data packet 

flows forwarded on the IP-based user plane from a common, IP-based control 

plane provided with one or more midcom agents, where the common, IP-based 
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control plane is separate from the IP-based user plane," steps (b) and (c) relate to 
registering "each mobile user data packet flow," and step (d) recites "the midcom 
agent signalling control orders to the registered middleboxes, said orders 
pertaining to the handling of the mobile user data packet flows at respective 
middleboxes in the IP-based user plane." Nowhere does the office action explain 
where either Mitchell or Suzuki teaches the registration and control of user data 
packet flows or mobile user data packet flows. 

The office action simply identifies "each flow (i.e. call set-up message)" on 
page 3. But a call set-up message is a control message and iiot an "individual 
mobile user data packet flow[] forwarded on an IP-based user plane, where each 
mobile user data packet flow is separate and different from session set up 
messages sent with IP layer control signaling and/or session layer control 
signaling," as recited in claim 1. Mitchell's call set-up message from terminal A 
to middlebox 1 (see step 60 in Fig. 7) and from middlebox 1 to the call server 18 
(see step 61 in Fig. 7) (mapped to the claimed midcom agent) cannot be mapped to 
the claimed mobile user data packet flow. 

The Examiner improperly ignores that claim 1 also explicitly recites: 
"where each mobile user data packet flow is separate and different from session 
setup messages sent with IP layer control signaling and/or session layer control 
signaling" and that the user plane and control plane are separate. 
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The data flow/bearer B shown in Figure 6 of Mitchell does not register its 
presence in each middle box as recited in step b of claim 1 : "each mobile user 
data packet flow registering its presence in each middlebox it encounters on its 
way from its source to its destination in the IP based user plane." In fact, the 
bearer connection B, which Applicants believe corresponds to the user data flow 
between the middleboxes 1 and 2 and users A and B in Figure 6, is not described 
in much detail by Mitchell outside of paragraph [0046]. The paragraph just 
emphasizes that signaling S and user data B are sent in the same plane between the 
user terminal and the middlebox. There are no separate control and user planes. 
No separate control plane is described for signaling between the terminal and call 
servers 18 which the Examiner maps to the claimed midcom agent. Ultimately, 
Mitchell does not disclose that each middlebox registers mobile user data packet 
flows. 

Nor does the Examiner identify what in Suzuki teaches "mobile flows" - let 
alone individual mobile user data packet flows. The office action simply identifies 
"network addresses" and "address information" which plainly is not individual 
mobile user data packet flows. So even if these two references could be 
combined, which they caimot be, they fail to teach the registration and control of 
individual mobile user data packet flows which cannot be mapped to call setup 
messages as asserted by the Examiner in the rejection. 
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3. Mitchell and Suzuki Lack the Claimed Middlebox and Midcom 
Agent Functionality 

Page 4 of the new office action admits that Mitchell lacks a teaching of 

multiple elements recited in claim 1 including for example: 

(1) middlebox registration at a midcom agent (mapped onto call 
servers/proxies 18 in Figure 6) or at middleboxes (mapped onto middleboxes 10, 
1 1) (see step b of claim 1), 

(2) "the common, IP-based control plane is separate from the IP-based user 
plane," and 

(3) "each mobile user data packet flow is separate and different from 
session set up messages sent with IP layer control signaling and/or session layer 

control signaling." 

These missing features (l)-(3) are in addition to the registration and control of 
individual mobile user data packet flows missing from Mitchell as explained in 
section 2 above. 

For the admitted missing features, the Examiner turns to Suzuki's abstract, 

figure 2, and col. 4, lines 17-24 which is quoted here for convenience: 

FIG. 4 shows the first method of the address deciding 
process. Referring to FIG. 4, an address server 1 
notifies routing nodes 2 to 5 connected to a main 
network 16 of addresses of the routing nodes 2 to 5. 
When a network address of a routing node is changed, 
the address server 1 notifies other routing nodes of 
relevant address change information. 
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First, the Examiner never clearly identifies what in Suzuki is the 
middlebox, midcom agent, control plane, or user plane. The "burden of proof [is] 
on the Patent Office which requires it to produce the factual basis for its rejection 
of an application under sections 102 and 103." In re Piasecki, 223 USPQ 785, 788 
(Fed. Cir. 1984). It is impossible for this burden to be met without some specific 
identification in the rejection of the mapping of these claim elements to specific 
features identified by reference numeral in Suzuki. 

The Examiner may be mapping Suzuki's routing nodes 2-5 to middleboxes 
and address server 1 to a midcom agent. But a person of ordinary skill would not 
make such a mapping. As a person of ordinary skill in the art would understand 
from the instant specification and from Mitchell, a middlebox processes user data 
packets . Examples of such middlebox processing include QoS differentiation or 
transcoding. In the claims in this case, this middlebox processing is controlled by 
a midcom agent. In contrast, Suzuki's invention is directed to something very 
different — handling address management for basic connectivity — not for 
processing user data packets. 

It is also important to remember that claim 1 is not simply reciting any node 
registering with another management node, which seems to be the Examiner's 
approach in the rejection. Rather, step c in claim 1 specifically recites: "in 
response to step b [user data flow registration in each middlebox], each middlebox 
in the IP based user plane registering itself and the identities of mobile user data 
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packet flows it handles in the IP based user plane at a midcom agent in the 
common, IP -based control plane using an extended midcom signalling protocol." 
Suzuki simply does not teach the claimed middlebox or midcom agent. Again, the 
the claim context and the meaning that a person of ordinary skill would ascribe to 
the claim terms in light of the specification and Mitchell may not be ignored. 

As a result, Suzuki cannot supply admitted missing feature (1) middlebox 
registration at a midcom agent (mapped onto call servers/proxies 18 in Figure 6) 
or at middleboxes (mapped onto middleboxes 10, 1 1) (see step b of claim 1). Nor 
does the office action explain where Suzuki teaches (2) "the common, IP-based 
control plane is separate from the IP-based user plane," and (3) "each mobile user 
data packet flow is separate and different from session set up messages sent with 
IP layer control signaling and/or session layer control signaling." The top of page 
5 of the office action simply describes the address server 1 in Suzuki notifying 
routing nodes 2-6 of their addresses and of changed routing node addresses. 

Ultimately, Mitchell and Suzuki do not disclose or suggest registering 
mobile user data flows that move between different middleboxes so that 
movement of a mobile terminal or a moving network can be accommodated. The 
Examiner never explains how fixed router node network addresses or address 
changes in Suzuki is the same as mobile user data flows. In addition, there is no 
teaching in Mitchell or Suzuki of registering the mobile user data flow identities at 
a midcom agent together with the identity of the middlebox that the flow traverses 
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in order to allow the user data flow to be bound to a specific flow control process 
in the midcom agent even though the flow may move between different 
middleboxes during the Hfe of the connection. 

Moreover, claim 1 is not reciting an IP-based control plane separate from 
an IP-based user plane in a vacuum . The Suzuki reference is a general router 
addressing reference, and the Examiner makes no attempt to identify where Suzuki 
teaches middleboxes, midcom agents, the interactions between them, and mobile 
user data packet flows. The piece-meal approach to the Examiner's rejection is 
evident and improper. Each claim and each reference must be considered as a 
whole. 

4. Mitchell and Suzuki Lack Additional Features from Claim 12 

Claim 12 recites plural IP networks and a session controller in addition to a 
midcom agent. The office action identifies the same call server as both the session 
controller in addition to the midcom agent. This cannot be correct. Claim 12 
recites that each network includes a midcom agent, but the session controller is a 
separate entity that sets up the path over the plural networks. Mitchell's call 
server is most reasonably read onto the session controller and not to the midcom 
agent. 

Nor do Mitchell's middleboxes 1 and 2 satisfy the claim language that 

"each selected network having an ingress middlebox. . .and an egress 
middlebox. . . ." The first network identified by the Examiner as address realm D 1 
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only shows one middlebox 1, and the second network identified by the Examiner 
as address realm D2 only shows one middlebox 2. 

5. Mitchell and Suzuki Lack Additional Features from Claim 20 
The middlebox of claim 20 "receive[s] a midcom agent announcement 

message, the midcom agent located in a control plane separate from the IP-based 
user plane in which the middlebox is located." The office action on pages 14-15 
never identifies where this language is taught by either Mitchell or Suzuki. This 
claim element is simply and improperly ignored. 

6. The Combination of Mitchell and Suzuki Is Improper 

The Examiner tries to justify the combining Suzuki with Mitchell because it 
"would benefit the system to reliably route packets." But the Examiner never 
explains why or how Suzuki's network addressing scheme would be used in 
Mitchell. The object in col. 2, lines 43-46 of Suzuki used by the Examiner to 
support the combination and the quoted allegation deals with a moving routing 
node and managing address "in a multi-home format." But Mitchell is not using 
moving routers or a multi-home format, so this object is irrelevant. 

The mere fact that references might somehow be combined or modified 
does not render the resultant combination obvious unless the results would have 
been predictable to one of ordinary skill in the art. See, e.g., KSR International 
Co. V. Teleflexlnc, 82 USPQ2d 1385, 1396 (2007); MPEP §2143.01.111. No 
predictability is demonstrated by the Examiner. Indeed, the two references are 
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directed to very different problems and technology areas. It is not even explained 
how the two references would even be combined. 

In any § 103 analysis, it is also important to consider the problem that the 
inventors in this case identified and solved. The courts have long found that the 
problem confronted by the inventors must be considered in an obviousness 
inquiry. See, e.g.. Northern Telecom, Inc. v. Datapoint Corp., 908 F.2d 931, 935 
(Fed. Cir. 1990); In re Sponnoble, 405 F.2d 578, 585 (CCPA 1969) ("[A] 
patentable invention may lie in the discovery of the source of a problem even 
though the remedy may be obvious once the source of the problem is identified. 
This is part of the 'subject matter as a whole' which should always be considered 
in determining the obviousness of an invention under 35 U.S.C. §103."). 

Neither Mitchell nor Suzuki address the problems set forth in the Problem 
Description section of the specification on pages 3-4. And neither reference 
recognized that these problems could be solved by separating the user data plane 
from the IP control plane and registering the flows with the midcom agent, where 
the midcom agent then sends control messages, related to individual user data 
flows, to middleboxes, routers, and other nodes along the paths the individual 
flows traverse. As a result, control signaling is faster and is done from one unit — 
a midcom agent. The use of two separate signaling protocols to set up a session is 
eliminated thereby reducing complexity and bandwidth requirements. Upgrading 
of software is facilitated since only one control entity, the midcom agent, needs to 
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be upgraded. The central midcom agent also makes it is possible to handle flows 
in a consistent manner and avoid feature interaction. None of these advantages is 
recognized by Mitchell or Suzuki. 

The Obviousness Rejection of Claims 13 and 14 Under 35 U.S.C. §103 Based 
on Mitchell, Suzuki, and Das Is Improper 

The rejection of claims 13 and 14 is improper for the reasons set forth 
above including those set forth for independent claim 12. Although claim 13 does 
not recite a mobile user data packet flow, the admission on page 16 of the office 
action that neither Mitchell nor Suzuki teaches that "the user flow is a mobile 
packet flow" contradicts the rejection of step (a) of claim 1 which recites 
"controlling individual mobile user data packet flows." In other words, this 
admission undermines the main rejection based on Mitchell and Suzuki. 

Das at [0031] teaches a mobile registering with a foreign agent so the 
foreign agent can be used as a care-of address for sending packets to the mobile or 
the mobile can use a collocated address to register with it home agent using mobile 
IP registration. But Das does not teach the missing features noted above for the 
independent claims and also adds another reference to the already improper 
combination of Mitchell and Suzuki. Again, the Examiner ignores the context of 
the claim and tries to use an alleged analogous feature from a very different type 
of system from what is taught by Mitchell. 
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The Obviousness Rejection of Claims 3 and 11 Under 35 U.S.C. §103 Based 
on Mitchell, Suzuki, and Ramsayer Is Improper 

The rejection of claims 3 and 1 1 is improper for the reasons set forth above. 
Moreover, Ramsayer also adds another reference to the already improper 
combination of Mitchell and Suzuki. 

CONCLUSION 

The combinations in the final rejection fail to establish a prima facie case of 

obviousness for multiple independent reasons. The final rejection should be 

reversed and the application passed to allowance. 

Respectfully submitted, 
NIXON & VANDERHYE P.C. 

By: /John R. Lastova/ 

John R. Lastova 

JRL/maa Reg. No. 33,149 

Appendix A - Claims on Appeal 
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VIII. CLAIMS APPENDIX 

1. (Previously Presented) A method for control of mobile packet flows forwarded on 
an IP-based user plane, where each mobile user data packet flow is separate and different 
from session set up messages sent with IP layer control signaling and/or session layer 
control signaling, comprising the steps of : 

a. controlling individual mobile user data packet flows forwarded on the IP- 
based user plane from a common, IP-based control plane provided with one or more 
midcom agents, where the common, IP-based control plane is separate from the IP- 
based user plane, said control being provided by: 

b. each mobile user data packet flow registering its presence in each 
middlebox it encounters on its way from its source to its destination in the IP-based 
user plane, and 

c. in response to step b, each middlebox in the IP-based user plane registering 
itself and the identities of mobile user data packet flows it handles in the IP-based 
user plane at a midcom agent in the common, IP-based control plane using an 

extended midcom signalling protocol, and 

d. after step c, the midcom agent signalling control orders to the registered 
middleboxes, said orders pertaining to the handling of the mobile user data packet 
flows at respective middleboxes in the IP-based user plane. 
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2. (Previously Presented) A method in accordance with claim 1, further comprising 
the midcom agent sending its control orders to an individual mobile packet flow via the 
middlebox at which said mobile packet flow registers. 

3. (Previously Presented) A method in accordance with claim 1, further comprising 
the midcom agent sending its control orders to an individual mobile packet flow via 
another midcom agent than that at which the mobile packet flow registered. 

4. (Previously Presented) A method in accordance with claim 1, further comprising 
the midcom agent using the identity of the middlebox that registered in order to find the 
functionality the middlebox has and provide a corresponding control order that it sends to 
the middlebox. 

5. (Previously Presented) A method in accordance with claim 1, wherein the 
midcom agent controls a number of middleboxes provided in a network comprising: 

a. an ingress middlebox, sitting on the edge of the network where an individual 
mobile packet flow enters the network, filtering out control messages and 
tunnelling them to the midcom agent, and 
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b.the midcom agent, in response sending control messages to each of the 

middleboxes it controls, dividing the IP layer into an IP control layer and an IP 
user plane. 

6. (Previously Presented) A method in accordance with claim 1, further comprising 
the midcom agent using a routing table to send control messages to the respective 
middleboxes on the IP control plane using an extended midcom protocol. 

7. (Previously Presented) A method in accordance with claim 1, further comprising 

the midcom agent sending control messages to the middleboxes by first sending them to 
the ingress middlebox from which they are sent in the same channel as the user data. 

8. (Previously Presented) A method in accordance with claim 1 , wherein a domain 
comprises middleboxes and a midcom agent, the method further comprising: 

a. forwarding control messages from one domain to another by having an ingress 
middlebox, sitting on the edge of a network at which an individual mobile packet 
flow enters, 

b. filtering out control messages and tunnelling them to the midcom agent, and 

c. the midcom agent forwarding them to an egress middlebox at which the mobile 
packet flow exits the network. 
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9. (Previously Presented) A method in accordance with claim 8, further comprising 
exchanging step c. for a step of returning a control message to the ingress middlebox 
from where it is forwarded along a same path as the user data flow. 

10. (Previously Presented) A method in accordance with claim 1, further comprising 
plural midcom agents, provided at the IP control plane, simultaneously controlling one 
and the same mobile packet flow. 

1 1 . (Previously Presented) A midcom agent comprising a plurality of control function 
sets, each set relating to the operation of an individual middlebox, and comprising control 
orders for control of the operation of the corresponding middlebox according to the 
method claimed in claim 1. 

12. (Previously Presented) A communication system comprising: 
a plurality of IP based networks; 

a session controller for set up of a communication path that traverses selected one 
of the networks, each selected network having an ingress middlebox at which a user data 
packet flow enters the network and an egress middlebox at which the flow exits the 
network, where the user data packet flow is separate and different from session set up 
messages sent with IP layer control signaling and/or session layer control signaling, 
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each network comprising: 

a midcom agent located in an IP control plane, 

a plurality of middleboxes located in an IP user plane separate from the IP 

control plane, 

an extended midcom protocol allowing for communication between the 
midcom agent and the middleboxes, 

wherein said middleboxes are configured to detect a user data packet flow 
forwarded on the IP-based user plane and register its identity at the midcom agent located 
in the IP control plane together with the identity of the middlebox at which the user data 
packet flow was detected, and 

wherein said midcom agent, in response to a combined flow and middlebox 
registration, is configured to send a flow control order to the middlebox in the IP-based 
user plane using the extended midcom protocol, said flow control order instructing the 
middlebox how to handle the detected user data packet flow in the IP-based user plane. 

13. (Previously Presented) The communication system in claim 12, wherein the user 
data packet flow is a mobile packet flow, and wherein in response to movement of a 
mobile terminal associated with the mobile packet flow, a new middlebox in the IP -based 
user plane is configured to detect the mobile packet flow and register the identity of the 
mobile packet flow and the identity of the new middlebox with the midcom agent located 
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in the IP control plane, and the midcom agent is configured to send a flow control order 
to the new middlebox instructing the new middlebox how handle the detected flow. 

14. (Previously Presented) The communication system in claim 12, wherein the user 
flow is a mobile packet flow, and wherein in response to movement of a network 
associated with the mobile packet flow, a new middlebox in the IP-based user plane is 
configured to detect the mobile packet flow and register the identity of the mobile packet 
flow and the identity of the new middlebox with the midcom agent located in the IP 
control plane, and the midcom agent is configured to send a flow control order to the new 
middlebox instructing the new middlebox how handle the detected flow. 

15. (Previously Presented) A midcom agent located in a control plane for controlling 
mobile user data packet flows over an IP-based user plane separate from the control 
plane, where each mobile user data packet flow is separate and different from session set 
up messages sent with IP layer control signaling and/or session layer control signaling, 
comprising electronic circuitry configured to: 

receive a middlebox registration message from each of multiple middleboxes in 
the IP-based user plane; 

register each middlebox for which a middlebox registration message is received; 

receive from each of the registered middleboxes one or more mobile user data 
packet flows being handled by each of the registered middleboxes in the IP-based user 
plane; and 
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signal a control order to each of the registered middleboxes for handling the 
mobile user data packet flows at each of the registered middleboxes. 

16. (Previously Presented) A midcom agent in accordance with claim 15, wherein the 
midcom agent is configured to send its control orders to an individual mobile user data 
packet flow via the middlebox at which said mobile packet flow registers. 

17. (Previously Presented) A midcom agent in accordance with claim 1 5, wherein the 
midcom agent is configured to use the identity of the middlebox that registered in order 
to find the functionality the middlebox has and provide a corresponding control order that 
it sends to the middlebox. 

18. (Previously Presented) A midcom agent in accordance with claim 15, wherein 
the midcom agent is configured to control a number of middleboxes provided in a 
network comprising: 

a. an ingress middlebox, sitting on the edge of the network where an 
individual mobile packet flow enters the network, filtering out control 
messages and tunnelling them to the midcom agent, and 

b. the midcom agent, in response sending control messages to each of the 
middleboxes it controls, dividing the IP layer into an IP control layer and an 
IP user plane. 
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19. (Previously Presented) A midcom agent in accordance with claim 15, wherein the 
midcom agent is configured to use a routing table to send control messages to the 
respective middleboxes on the IP control plane using an extended midcom protocol. 

20. (Previously Presented) A middlebox for controlling mobile user data packet flows 
over an IP-based user plane, where each mobile user data packet flow is separate and 
different from session set up messages sent with IP layer control signaling and/or session 
layer control signaling, comprising electronic circuitry configured to: 

receive a midcom agent announcement message, the midcom agent located in a 
control plane separate from the IP-based user plane in which the middlebox is located; 

send a middlebox registration message to the midcom agent; 

send a mobile user data packet flow registration message to the midcom agent for 
one or more mobile packet user data flows being handled by the middlebox in the IP- 
based user plane; and 

receive a control message from the midcom agent in the control plane for handling 
the one or more mobile user data packet flows in the IP-based user plane. 
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IX. EVIDENCE APPENDIX 

There is no evidence appendix. 

X. RELATED PROCEEDINGS APPENDIX 

There is no related proceedings appendix. 
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